A computer network is a geographically distributed collection of interconnected subnetworks for transporting data between nodes, such as computers. The network's topology is defined by an arrangement of client nodes that communicate with one another, typically through one or more intermediate nodes. As used herein, a client node is an endstation node that is configured to originate or terminate communications over the network. In contrast, an intermediate node is a network node that facilitates routing data between client nodes. Communications between nodes are typically effected by exchanging discrete packets of data according to predefined protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.
Each data packet typically comprises “payload” data prepended (“encapsulated”) by at least one network header formatted in accordance with a network communication protocol. The network headers include information that enables the client nodes and intermediate nodes to efficiently route the packet through the computer network. Often, a packet's network headers include at least a data-link (layer 2) header and an internetwork (layer 3) header, as described by the Open Systems Interconnection (OSI) Reference Model. The OSI Reference Model is generally described in more detail in Section 1.1 of the reference book entitled Interconnections Second Edition, by Radia Perlman, published September 1999, which is hereby incorporated by reference as though fully set forth herein.
The data-link header provides information for transmitting the packet over a particular physical link (i.e., a communication medium), such as a point-to-point link, Ethernet link, wireless link, optical link, etc. To that end, the data-link header may specify a pair of “source” and “destination” network interfaces that are connected by the physical link. A network interface contains the mechanical, electrical and signaling circuitry and logic used to couple a network node to one or more physical links. In general, a network interface may contain one or more ports that connect to different communication mediums. As used herein, a port is a physical interface through which a physical link is attached to a network interface. A network interface is often associated with a hardware-specific address, known as a media access control (MAC) address. Accordingly, the source and destination network interfaces in the data-link header are typically stored as source and destination MAC addresses. The data-link header may also store flow control, frame synchronization and error checking information used to manage data transmissions over the physical link.
The internetwork header provides information defining the packet's logical path (or “virtual circuit”) through the computer network. Notably, the path may span multiple physical links. The internetwork header may be formatted according to the Internet Protocol (IP), which specifies IP addresses of both a source and destination node at the end points of the logical path. Thus, the packet may “hop” from node to node along its logical path until it reaches the client node assigned to the destination IP address stored in the packet's internetwork header. After each hop, the source and destination MAC addresses in the packet's data-link header may be updated, as necessary. However, the source and destination IP addresses typically remain unchanged as the packet is transferred from link to link in the network.
Client nodes may be configured to communicate over various types of networks, ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect client nodes over dedicated private communications links located in the same general physical location, such as in a home or an office building. WANs typically connect large numbers of geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines. The Internet is an example of a WAN that connects disparate networks throughout the world, providing global communication between nodes contained in various networks.
A plurality of LANs and WANs may be interconnected by an intermediate node, such as a router or switch, to extend the effective “size” of the computer network and increase the number of communicating nodes. For example, one or more intermediate nodes may be employed to extend a LAN belonging to a particular organization (or “enterprise”) beyond the geographic boundaries of that organization. The intermediate nodes enable authorized telecommuters, e.g., working from a home office, to remotely connect to the enterprise LAN. In an illustrative case, the telecommuter establishes a communication session with a local intermediate node, which in turn establishes a communication session with a remote intermediate node in the enterprise network. Once connected in this manner, the telecommuter can access resources and services provided in the enterprise network as if he/she were physically present in the organization.
Because the local and remote intermediate nodes may be coupled over an untrusted public network, such as the Internet, the nodes may be configured to communicate using a more secure, “trusted” subnetwork implemented over the public network. The trusted subnetwork employs cryptographically secure communications sent over the larger, “untrusted” public network. In effect, the trusted subnetwork functions as a virtual “tunnel” that protects data communicated between the intermediate nodes. For instance, a virtual private network (VPN) may be employed by the intermediate nodes to ensure the privacy of their communicated data. To that end, data packets may be encrypted when they “enter” the VPN tunnel at one of the intermediate nodes, and decrypted when they “exit” at the other intermediate node. Conventional tunneling protocols, such as the Layer 2 Tunneling Protocol (LT2P), Point to Point Tunneling Protocol (PPTP) and the IP Security (IPSec) Protocol are known in the art for encapsulating communications through the VPN tunnel.
Although the VPN tunnel may be constructed to securely transfer data over an untrusted network, a remote user (i.e., a telecommuter) typically should be authenticated before being granted access to the tunnel. By requiring user authentication in this way, the enterprise network is protected from unauthorized users gaining access to the enterprise's VPN tunnel (i.e., “enterprise VPN”). User authentication is typically implemented at an intermediate-node port coupled to the enterprise VPN. The port assumes one of two possible states: “open” or “closed.” Initially, the port's state is closed, thereby preventing client-node access to the enterprise VPN. However, after a user is authenticated at the port, the port changes to an open state. The open port enables the authenticated user to access the enterprise VPN. Besides providing access to the VPN tunnel, the open port may also provide other specialized services, such as enhanced quality of service, that are not available through the port in its closed state.
A popular technique for implementing this type of conventional port-based security is described in The Institute of Electrical and Electronics Engineers' (IEEE) standard IEEE Std 802.1X-2001 entitled Port-based Network Access Control, published July 2001, which is hereby incorporated by reference as though fully set forth herein. In this standard, a client node executes a “supplicant” port access entity (PAE) at a client-node port, and an intermediate node executes an “authenticator” PAE at an intermediate-node port coupled to the client-node port. The supplicant and authenticator PAEs are configured to transmit and receive data packets formatted in accordance with the 802.1X standard.
The intermediate node's port is initially in an uncontrolled state (i.e., a “closed state), whereby all client-node communications at the port are directed to the authenticator PAE. The supplicant PAE at the client node generates an 802.1X authentication request to change the intermediate node's port to a controlled state (i.e., an “open” state). As per the 802.1X standard, the request is formatted according to the Extensible Authentication Protocol (EAP) and encapsulated in a conventional IEEE 802 data frame. The EAP protocol is described in more detail in Request for Comments (RFC) 2284 entitled PPP Extensible Authentication Protocol (EAP), published March 1998, and the IEEE 802 standard is generally described in IEEE Std 802-2001 entitled 802 IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, published February 2002, both of which are hereby incorporated by reference as though fully set forth herein. Advantageously, the EAP protocol is a generic protocol capable of supporting various different authentication techniques. Thus, the supplicant PAE may generate the 802.1X authentication request in accordance with any authentication method consistent with the EAP protocol. When the client node and intermediate node are connected via a shared LAN segment, the supplicant PAE formats the request as an EAP over LAN (EAPOL) packet and forwards it to the intermediate node.
At the intermediate node, the EAPOL packet is received by the authenticator PAE, which processes and forwards the request to an appropriate authentication service, such as a Remote Authentication Dial-In User Service (RADIUS). If necessary, the request may be reformatted by the authenticator PAE, e.g., in accordance with an EAP over RADIUS protocol, before being forwarded to the authentication service. The EAP over RADIUS protocol is described in more detail in RFC 2869 entitled RADIUS Extensions, published June 2000, which is hereby incorporated by reference as though set forth fully herein.
Upon receiving the request, the authentication service provides authentication, authorization and accounting (AAA) functions to determine whether a user at the client node may be authenticated at the intermediate node's port. The AAA procedures are performed in accordance with the authentication method specified by the user's EAP request. Accordingly, the AAA procedures may require that a sequence of challenge response exchanges be performed between the authentication service and the client node. Upon completion of these procedures, the authentication service notifies the authenticator PAE of the user's authentication state. If the user is authenticated, then the authenticator PAE changes the intermediate-node port's state to controlled, thereby enabling the user to access the enterprise VPN and other intermediate-node services. Otherwise, the intermediate node's port remains in an uncontrolled state. This 802.1X authentication process is typically repeated periodically to verify that the user's authentication state at the intermediate-node port does not change, e.g., from authenticated to unauthenticated.
While the above-noted 802.1X authentication procedure works well for intermediate-node ports coupled to individual client nodes, it does not scale well when a plurality of client nodes is coupled to a shared media port in the intermediate node. As used herein, a shared media port is a physical interface that connects a network interface to one or more physical links coupled to a plurality of other network interfaces. For example, the shared media port may include an integrated hub or switch through which the port is connected to a plurality of remote network interfaces. Alternatively, the port may be connected to a “downstream” hub or switch that couples the port to a plurality of remote network interfaces. By way of example, a telecommuter working from home may access an enterprise VPN through a shared media port in a “home” (i.e., local) intermediate node. At the same time, one or more family members working from different computers in the home may establish separate network connections through the same shared media port.
Network security problems often arise when both authorized and unauthorized users communicate through a shared media port that is configured to perform port-based network access control, such as 802.1X authentication. As noted, the shared media port transitions from an unauthorized to an authorized state once a user is authenticated at the port. Consequently, unauthenticated users at client nodes coupled to the shared media port may gain unauthorized access to the intermediate node's services as soon as a user is authenticated at another client node coupled to that port. In this situation, network security may be compromised by the unauthenticated users coupled to the authorized port. This problem may be exacerbated when an access point (AP) is connected to the shared media port, since the AP can serve as a gateway for a potentially large number of unauthenticated users as wireless client nodes. Unfortunately, the IEEE 802.1X standard does not address the possibility of such security breaches at shared media ports.
Previously, the above-noted security problems have been addressed by employing network access control within client nodes coupled to the shared media port. The client nodes are configured to determine whether their respective users are authorized to access a trusted subnetwork (e.g., an enterprise VPN) through the shared media port, even when the port is already in an authorized state. For example, an organization may install a list of allowed client nodes, so only those client nodes on the list are permitted to access the organization's enterprise VPN. Although this solution essentially extends conventional port-based network access control for client nodes connected to a shared media port, the solution has a number of significant drawbacks.
First, maintaining and distributing updated lists of authorized client nodes is an arduous task for large organizations. In the event that the organization has issued a large number of client nodes, e.g., to its telecommuters, the distribution of updated lists may be extremely difficult to deploy in a timely manner. Further, because authorized client nodes may join and leave the organization at relatively high frequencies, the time and resources consumed while maintaining such lists may be prohibitive. Second, because access control to the enterprise VPN is implemented in a potentially large number of client nodes, each client node is a possible point at which the VPN's network security may be compromised. Thus, configuring and maintaining security measures in a large number of client nodes also may consume excessive time and resources. In addition, allowing access based upon the client node does not authenticate the user on that node. That is, an authorized client node may be controlled by an unauthorized user.
It is therefore desirable to provide a more efficient and secure authentication technique at shared media ports. The technique should be compatible with conventional portbased security, such as 802.1X authentication, and should provide as high a level of network security. Further, the technique should not consume excessive time and resources to deploy to a large number of client nodes. It is also desirable that the technique not rely on security measures implemented in individual client nodes coupled to the shared media port.